Existing Internet protocol Multimedia Subsystems (IMS) registration procedures provide a single registration using the Session Initiation Protocol (SIP), which is generally effective for enabling a user to access most IMS-based services. Completion of the registration procedure generally results in the receipt of a security context in the form of a set of keys from an execution of an authentication and key agreement, which enables the user to access the IMS-based services. For example after IMS registration, the user can use multimedia telephony, instant messaging, presence, conferencing, as well as other IMS-based services generally without the need for further authentication.
Nevertheless, even after the user has executed an IMS registration, there are still instances in which the user needs to execute a further authentication as a result of contacting an IMS application server. At least a couple of examples of corresponding instances resulting in a further authentication includes instances in which a user wishes to access supplementary services including accessing or changing operating parameters or options that can be set in the network. At least a couple of examples include altering settings for multimedia telephone or settings for call forwarding, changing one's presence preferences, pulling policies from a server (i.e. Voice Call Continuity (VCC) policies), requesting a certificate from the server, and/or creating or editing a resource list (i.e. Push-To-Talk (PTT) contact list). In such instances, an additional security context involving a further authentication separate from the IMS security context is typically necessary between the user device and the application server. Such a supplemental authorization associated with the exemplary group of actions noted above is commonly referred to as a generic bootstrapping authentication.
Such an authentication differs from the IMS registration in that it commonly involves a HyperText Transfer Protocol (HTTP) digest Authentication and Key Agreement (AKA) authentication, in order to generate bootstrapping key material for use in accessing the application server(s). As a result, in addition to supporting AKA authentication as part of a SIP communication, the bootstrapping authentication involves AKA authentication support as part of an HTTP communication. Still further the additional authentication as presently provided in addition to being separately requested, also generally results in the authentications being separately refreshed including a second separate set of communications that are used to maintain the separate authentication and the corresponding key material and/or security context.
The present inventors have recognized that it would be beneficial to develop an apparatus and/or approach, which would enable multiple authentications to be managed as part of a single joint request.